Flight management systems, commonly referred to by the acronym FMS, have in their main jobs to provide the crew with a strategic overview of their flight, this including for example the construction of a trajectory between waypoints or a precise description of the manoeuvres that the aircraft will perform to carry out the flight plan. FMS systems thus determine a set of implicit points and of segments between these waypoints. A significant role of FMS systems is the construction of a trajectory achievable as a function of a flight domain of the aircraft, and including the transitions between the various segments. A major expectation of flight management systems is the prediction of the temporal and fuel consumption aspects along this computed trajectory. What will be the transit times at the various points, what quantity of fuel will be required in order to achieve the flight, what manoeuvre is it preferable to engage under these conditions, are all questions to which an FMS system must respond.
Existing systems are being called into question on account of the constant increase in air traffic and the emergence of complex functions making it possible to save fuel and to guarantee compliance with transit times. A novel computation architecture and a breakaway mode of representation of the trajectory are thus proposed by the present invention.
In the known state of the art, the computed trajectory is split between a lateral trajectory, typically a latitude and a longitude, and a vertical profile applied to this lateral trajectory. Thus, two uncoupled modules produce two distinct trajectories, lateral and vertical, which are subsequently gathered to form an essentially geometric definition of the trajectory of the aircraft. The temporal and fuel aspects are computed subsequently, after assembling the lateral and vertical trajectories.
FIG. 1 presents the functional architecture of an FMS system according to the known state of the art. In accordance with the ARINC 702 standard, they ensure notably the functions of:                Navigation LOCNAV, 170, for performing optimal location of the aircraft as a function of the geo-location means (GPS, GALILEO, VHF radio beacons, inertial platforms, etc.),        Flight plan FPLN, 110, for inputting the geographical elements constituting the skeleton of the course to be followed (departure and arrival procedures, waypoints, etc.),        Navigation database NAVDB 130, for constructing geographical courses and procedures with the help of data included in the bases (points, beacons, interception or altitude legs, etc.),        Performance database, PRF DB 150, containing the craft's aerodynamic and engine parameters,        Lateral trajectory TRAJ, 120, for constructing a continuous trajectory on the basis of the points of the flight plan, complying with the performance of the aircraft and the confinement constraints,        Predictions PRED, 140, for constructing an optimized vertical profile on the lateral trajectory,        Guidance, GUID 200, for guiding in the lateral and vertical axis the aircraft on its 3D trajectory, while optimizing the speed,        Digital data link DATALINK, 180, for communicating with the control centres and other aircraft.        
On the basis of the flight plan FPLN defined by the pilot, a lateral trajectory is determined as a function of the geometry between the waypoints and/or the altitude and speed conditions, by means of the module TRAJ 120. On the basis of this lateral trajectory, a prediction function PRED 140 grafts the vertical flight plan elements (altitude constraint, speed constraint or wind constraint, change of cruising level, etc.), that may induce the resumption of certain parts of the lateral trajectory.
A difficulty with trajectory construction in the known systems can be illustrated by the example of the construction of the descent profile, and notably the determination of the start-of-descent ToD point, or “Top of Descent”, which is the point where the aircraft terminates its cruising to start its descent towards its landing field. A specific iterative process determines this point, by a first “reverse direction” step which determines the ToD point on the basis of a hypothetical state of the aircraft at the landing point, and a second “forward” step of the state of the aircraft at the landing point starting from this estimated ToD point; the iterative process being continued until the identification of a common trajectory, in the forward direction and in the backward direction. This computation, which involves a certain number of iteration to converge to the start-of-descent point, is complex and induces a heavy load on the computing resources of the computer. According to the same principle, the construction of a continuously ascending trajectory, envisioned within the framework of the optimization of air traffic, makes it necessary to develop complex iterative processes that consume considerable computing time.
Another known difficulty resides in the resolution of discontinuities which can appear when computing the lateral trajectory. In accordance with the ARINC 424 standard, a lateral trajectory is constructed between various waypoints by stringing together standardized flight portions, generally called “legs”. A lateral trajectory is determined at one and the same time by forward and backward computations, aimed at convergence; the result being a geometric trajectory. The computation of the points of convergence, between the forward and backward computations, can lead to discontinuities, both lateral and vertical.
This difficulty, well known to the person skilled in the art, can be illustrated by the two conventional cases of discontinuity presented in FIGS. 2a and 2b. FIG. 2a describes a discontinuity of so-called “Bird” type. The flight plan defines a skeletal trajectory, passing through two intermediate points 11 and 12, forming three segments 13, 14 and 15. The lateral trajectory computation determines, in the forward direction, a first “leg” 16, allowing the aircraft to join the segment 14 from the segment 13. In the backward direction, the trajectory computation determines a second “leg” 17 allowing the aircraft to join the segment 15 from the segment 14. There is discontinuity between the two non-secant trajectories 16 and 17. The forward and backward trajectory computation fails to define a flyable trajectory making it possible to ensure the transition between the segment 13 and the segment 15.
FIG. 2b describes a discontinuity of so-called “Fish” type. The flight plan establishes a skeletal trajectory passing through two intermediate points 21 and 22, forming three segments 23, 24 and 25. The lateral trajectory computation determines, in the forward direction, a first “leg” 26 for joining the segment 24 from the segment 23. In the backward direction, the trajectory computation determines a second “leg” 27 allowing the aircraft to join the segment 25 from the segment 24. There is discontinuity between the two secant trajectories, 26 and 27. The forward and backward trajectory computation fails to define a flyable trajectory making it possible to ensure the transition between the segments 23 and 25.
Other cases also exist leading to such discontinuities, each of them requiring specific code elements to detect them and determine a solution in order to solve them. This results in a complex flight management system, requiring a lengthy and expensive verification and validation process.
To respond to real-time constraints, it is moreover desirable to carry out specific computations over a reduced time horizon so as to have a trajectory in a short time frame. To ensure permanent validity of the trajectory, the latter must be completely recomputed periodically, generating a computational load which monopolizes a significant share of the computational resources in the case of the known FMS systems. Lastly, moreover, the final resulting trajectory carries only a limited amount of information, typically the transit time and the fuel onboard when passing through navigation points.